Sure, here are the steps.

The update process consists of the following key steps:

1. Cleanup:
Purpose: Remove any existing BoringSSL source files and generated files.
Location: The script targets the third_party/boringssl directory and darwin/third_party/boringssl
Action: The cleanup() function removes the content of these folders.
Reason: This step ensures a clean slate, preventing conflicts with old files when integrating the new version.

2. Fetch Latest Revision:
Purpose: Determine the most recent commit hash from the official BoringSSL repository.
Source: The script queries the BoringSSL repository at https://boringssl.googlesource.com/boringssl/+log/master?format=JSON.
Action: The get_latest_revision() function:
Makes an HTTP request to the URL above.
Parses the JSON response.
Extracts the hash of the latest commit.
Return the commit hash.
Reason: By getting the latest revision from the repository, we are sure to work with the latest version.

3. Copy BoringSSL:
Purpose: Retrieve the BoringSSL source code and replace the existing version.
Action: The copy_boringssl(target) function:
Clone the boringssl at the temporary directory with the selected revision or the latest revision.
Copy the BoringSSL files from the target/src folder to the third_party/boringssl directory.
Reason: This step is the core of the update, replacing the older files with the new version's files.

4. Bump Revision:
Purpose: Update the BORINGSSL_REVISION variable within the update-boringssl.py script to reflect the new commit hash.
Action: The bump_revision(new_revision) function:
Reads the update-boringssl.py script file.
Locates the line defining BORINGSSL_REVISION.
Replaces the old revision with the new_revision (the fetched commit hash).
Saves the updated content back to the script file.
Reason:This ensures that the script itself keeps track of the currently used BoringSSL version, allowing for consistent future updates and traceability.

Let's do this in two PRs.

(1) PR that lands a script for rolling a BoringSSL update.
(2) PR that actually does the change.

In practice, we probably need to have me or someone else trusted run (2), in an ideal world we can run it in Github Actions.

It's simply impossible to even attempt to review this PR, and we absolutely can't a BoringSSL update without being able to prove that the files from BoringSSL have not been tampered with. Nothing personal, but I think everyone wants to be certain the files are copied over correctly :D